Systems and Methods for Shared Task Management

ABSTRACT

A task management system is disclosed for providing shared task management among a variety of users and allows users to create and share task-lists and tasks. Users can invite others to join task-lists and can assign responsibility for tasks to other users. In various embodiments, the system implicitly sets permissions for every task-list and task, and these permissions are automatically changed or updated by the system in response to users interacting with the system. In another embodiment, users can explicitly set these permissions. Thus, the task management system is configured so that there is no single administrator of the system; rather each user may be an administrator of certain tasks and task-lists and thus set the related task and task-list permissions. Thus, the system is configured to operate in the absence of explicitly set permissions, but is also flexible to allow for users to change and modify permissions explicitly.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.11/422,120, filed on Jun. 5, 2006, which is hereby incorporated hereinin its entirety by reference.

FIELD OF THE INVENTION

The present invention provides for systems and methods for shared taskmanagement in a computer network environment.

BACKGROUND OF THE INVENTION

The “to do” list is a familiar item for many persons to track tasks thatmust be done both at work and at home. Such lists commonly include thethings they need to accomplish on a particular day, in a particularweek, or in a particular month or year. Often these “to-do” lists arefor job-related tasks (such as projects, meetings, phone calls, etc.),family- or home-related tasks (such as chores, family vacations, etc.),or personal tasks (such as errands, exercising, etc.).

Frequently, people can forget to create to-do lists for these tasks, andcan ultimately forget to perform these tasks. In other instances, peoplemay have tasks in common with others (such as a husband sharing a commontask with his wife, such as making reservations for a weddinganniversary dinner), but may fail to communicate or share these taskswith others.

Currently known task management systems fail to solve these and otherproblems, and have even created additional problems with regard tosharing tasks among a variety of users. These systems can be cumbersometo use and make it difficult for users to share tasks with others. Adrawback of many known task management systems is that they may requirea single administrator to set all permissions of the system, or theyrequire users to explicitly set permissions of each task created, suchas by explicitly setting permissions for those users with whom the userdesires to share a task. Another drawback is that a user may not be ableto specify which tasks to share with others, but may only have theoption of sharing all tasks with others, and then have to manuallyselect those tasks which the user would like to maintain as private.Thus, as the number of tasks pertaining to a user steadily increases,the chore of maintaining and setting permissions of the tasks becomesincreasingly cumbersome.

Because of the permissions model of many current systems, these systemsalso make it difficult for a first user to see the tasks assigned toanother user. A first user may desire to see tasks assigned to a varietyof other users in order to determine which user is the least busy, so asto then assign a task to that user. However, in many instances, a firstuser may only be able to see tasks assigned to a second user if thesecond user has explicitly enabled the first user to see his tasks.Thus, when a user desires to assign a task to another user, he may notbe able to first determine how busy the other user is prior to assigninghim a task.

“Spam” email has become a common problem with users of electronic mailsystems, and this problem has the potential to pervade known taskmanagement systems. Because of the threat of “spam”, known taskmanagement systems are restricted to a limited audience, thus preventingthe sharing of tasks among a wide variety of users.

Therefore, there is a need for improved systems and methods for sharedtask management which solves these and other problems.

BRIEF SUMMARY OF THE INVENTION

The various embodiments of the invention overcome the problems notedabove and achieve significant advantages over previous approaches totask management.

One aspect of the present invention is a task management systemconnected to a communication network with one or more users operatingrespective computing devices. The task management system is comprised ofone or more task management computers executing an application withwhich the users interact via the respective computing devices. The taskmanagement computer is configured to enable one or more first users togenerate a designation of one or more second users to a task-list ortask, which is a member of one or more task-lists. The tasks andtask-lists have associated permissions, which the task managementcomputer changes automatically with respect to the second users based onthe first-user designation.

In one aspect, the first-user designation comprises a selection of oneor more second users to join a task-list, the selection being made froma list of one or more potential second users who may join the task-list.

In another aspect, the first-user designation comprises a selection ofone or more second users to be made responsible for a task, theselection being made from a list of one or more potential second userswho may be made responsible for the task.

Another aspect of the present invention is a computer-readable storagemedium storing an application for shared task management among one ormore users. The application directs a computer to perform the steps of:(1) receiving from a first user a designation of one or more secondusers to a task-list or task, the task being a member of one or moretask-lists, the task-list and task having associated permissions; and(2) automatically changing the task-list and task permissions based onthe first-user designation.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Having thus described the invention in general terms, reference will nowbe made to the accompanying drawings, which are not necessarily drawn toscale, and wherein:

FIG. 1 is a general diagram of a Task Management System, including atask management computer, according to one embodiment of the presentinvention.

FIG. 2 is a diagram of a Task Management System, including one or moretask management servers, according to one embodiment of the presentinvention.

FIG. 3A is a flow diagram illustrating several interactions that a usermay have with a Task Management System, and how the Task ManagementSystem automatically updates permissions in response to theinteractions, according to one embodiment of the present invention.

FIG. 3B is a flow diagram illustrating several interactions that a usermay have with a Task Management System, and how the Task ManagementSystem automatically updates permissions in response to theinteractions, according to another embodiment of the present invention.

FIG. 4 illustrates a task-list aliasing feature of a Task ManagementSystem, according to one embodiment of the present invention, whichdemonstrates that one or more task-lists may contain the same membergroup of tasks.

FIG. 5 is a flow diagram illustrating the steps of a Task ManagementSystem populating a heuristic list of potential users who may beassigned to a task, or invited to a task-list by another user of theSystem, according to one embodiment of the present invention.

FIG. 6 is a flow diagram illustrating the steps of a Task ManagementSystem updating a catalog of watched task-lists and tasks that isvisible to a user utilizing the Differential Update feature, accordingto one embodiment of the present invention.

FIG. 7 illustrates the concept of “known” users of a Task ManagementSystem, according to one embodiment of the present invention.

FIG. 8 is an exemplary screenshot, illustrating the catalog of tasks andtask-lists visible to a user, according to one embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

The present inventions now will be described more fully hereinafter withreference to the accompanying drawings, in which some, but not allembodiments of the inventions are shown. Indeed, these inventions may beembodied in many different forms and should not be construed as limitedto the embodiments set forth herein; rather, these embodiments areprovided so that this disclosure will satisfy applicable legalrequirements. Like numbers refer to like elements throughout.

Glossary

The following terms are defined below in order to allow for a betterunderstanding of embodiments of the present invention. However, theterms are not meant to be limited to the definitions provided below, andmay be understood further from the descriptions provided throughout, aswell as in light of ordinary definitions known to those of ordinaryskill in the art.

‘Computer’ or ‘computing device’ broadly refers to any kind of devicewhich receives input data, processes that data through computerinstructions in a program, and generates output data. Such computer canbe a hand-held device, laptop or notebook computer, desktop computer,minicomputer, mainframe, server, cell phone, personal digital assistant,other device, or any combination thereof.

‘Connected’ refers to a physical or wireless connection between twocomputing devices permitting communication of data. Two devices can beconnected directly together or indirectly through one or moreintermediate elements, through connection media that permitcommunication of data or a signal from one device to the other.Connection media include wire, optical fiber, or wireless transmission,for example.

‘Server’ can refer alternatively to a computing device or a programexecuting on one or more computing devices, which accepts request datafrom other computing devices or “client” applications, processes thedata through a set of computer instructions in the program, and returnsthe resulting processed data to the requesting computing device orclient application. Common servers include web servers, email servers,file servers, database servers, and network servers.

Overview

Various embodiments of the present invention are directed to a taskmanagement system for providing shared task management among a varietyof users. It is assumed that prior to using the task management system,various users have registered with the system such as by providing theirnames, desired usernames for the system, a password associated with theusername, and contact information including, for example, a phonenumber, address, and email address. In one aspect, the system allowsusers to create and share task-lists and tasks. Task-lists represent acollection of tasks; similarly, tasks are members, or subsets, oftask-lists, and are akin to “to-do” items, in that they represent afunction to be performed or an objective to be accomplished.

As an example, a user of the task management system may create atask-list entitled “Work”; the user would want tasks within the “Work”task-list be tasks related to the user's work, such as “Call Client”,“Attend Meeting”, etc. The user can then invite other users of thesystem to join the task-list, such as the user's co-worker(s). Inanother aspect, the user may want to make another user of the systemresponsible for a task, and thus assign the task to another user. Theseare some of the many ways in which a user may interact with the taskmanagement system.

In a further aspect, the system can set permissions for every task-listand task in the system, and these permissions are automatically changedor updated by the system in response to users interacting with the taskmanagement system, as will be described further below. In anotheraspect, task-list and task permissions can be set explicitly by users ofthe system, if so desired. In these aspects, the task management systemis configured so that there is no single administrator of the systemthat must set permissions for all users; rather each user may be anadministrator of certain tasks and task-lists and thus set the relatedtask and task-list permissions. Thus, the system is configured tooperate in the absence of explicitly set permissions, but is alsoflexible to allow for explicitly set permissions.

Structure of an Exemplary Task Management System

As shown in FIG. 1, in various embodiments the task management system 2generally includes one or more users 10 interfacing with a usercomputing device 12, using various input devices (e.g., keyboard, mouse,touch-screen, wand, stylus, voice receiver, or other device) and outputdevices (e.g., display, monitor, printer, speaker, or other device). Theuser computing device 12 is connected to a task management computer 16through a network 14, such as a Wide Area Network (WAN, such as theInternet), or Local Area Network (LAN). As described above, the taskmanagement system 2 is configured to allow users to interact with thetask management computer 16 to manage and share tasks and task-lists.Users can create task-lists and tasks, assign responsibility for tasksto other users, organize tasks into task-lists, invite other users towatch or join certain task-lists, watch task-lists to which they havebeen invited and watch tasks within those task-lists, and view tasksassigned to other users, among other functions. The task managementcomputer 16 supports these user interactions by manipulating theaforementioned task-list and task permissions, along with user specificpermissions, in the attached database 18. The database 18 may be localto the task management computer 16, or may be located remotely as shownin the FIG. 1.

The task management computer 16 may be understood, in variousembodiments, to refer collectively to one or more computing devicesexecuting a client program, such as a web server or thick client,connected to one or more task management servers. A task managementcomputer 16 may also encompass the task management servers, and/or amultiplexing gateway. Thus, in one embodiment of the present invention,the task management computer 16 as shown in FIG. 1 may be the globalprovider site 200 as shown in FIG. 2.

In various embodiments, the database 18 is configured to store datarelated to tasks and task-lists, as well as data associated with usersof the task management system 2. For instance, data maintained for eachtask can include a task name, description, one or more containing (or“parent”) task-lists, currently assigned user(s), default permissionsfor all users, notes or comments, a “last seen” or “last state” valuefor one or more users (see below), or other data. Similarly, datamaintained for each task-list can include a task-list name, description,default permission for all users, a “last seen” or “last state” valuefor one or more users, or other data. As discussed above, datamaintained for each user may include the user's name, a username,password, email address, contact information, permissions information,or other information.

A task management system 2 according to another embodiment of theinvention is shown in FIG. 2. As may be understood from this Figure, inthis embodiment, the system 2 includes a global communication network220 such as the Internet connecting a global provider site 200 withmultiple users, including one or more remote users 222, 224, and one ormore users 232, 242 local to one or more local customer sites 230. Anexemplary local customer site 230 can be a company, which has signed upfor service with the global provider, and has various users (such as itsemployees) that can connect to the global provider site 200 via a localarea network (LAN) 236 located within the local customer site 230.Alternatively, the local customer site can represent a group of users(such as users 232, 234) who share a common network, such as students ata university, members of a family, etc.

In the embodiment shown in FIG. 2, the local customer site 230 containsa local task management server 238 and an associated local database 240,which are configured to store or host tasks and task-lists related tothe local customer site 230. In this manner, confidential informationthat may be part of the tasks and task-lists can be stored locally tothe local customer site. The multiplexing gateway server 202, asdescribed below, is configured to allow tasks and task-lists of the taskmanagement system 2 to be stored on multiple task management servers(such as the global provider task management server(s) 210 and the localtask management server 238), which eliminates the need for a single,central server to store all tasks and task-lists for the task managementsystem 2.

In alternative embodiments (not shown), the local customer site 230 maynot include a local task management server or local database, so thattask, task-list, and user related information for the local users 232,242 would be hosted and stored on the task management server(s) 210 andassociated database(s) 212 at the global provider site 200.

An exemplary remote user 222, 224 may be an individual user of the taskmanagement system that connects directly to the task management system 2via a global communication network 220 (such as the Internet), as shownin FIG. 2. Local users and remote users utilize user computing deviceswhich can access the task management system services through a webbrowser connected to a web-based client application hosted at the globalprovider site 204 or through locally hosted client applicationsexecuting on the user computing devices communicating directly with themultiplexing gateway server 202 located at the global provider site 200.

As will be understood, such client applications can be implemented bycomputer program instructions. These computer program instructions maybe loaded onto the computers of various users of the system 2 or may beprovided by the global provider site 200 and hosted as a web-basedapplication as described above, such that the instructions which executeon the computer or other apparatus create the means for implementing thefunctions described herein. These program instructions may also bestored in a computer-readable memory that can direct a computer or otherapparatus to function in the particular ways described throughout.

The global provider site 200, as shown in FIG. 2, includes a web server204, multiplexing gateway server 202, and one or more task managementserver(s) 210 connected to associated database(s) 212. The databases 212are configured to store information as described above with respect tothe database 18 connected to the task management computer 16. The taskmanagement servers 210 are configured to process requests from one ormore associated client programs and to retrieve and manipulate user,task, task-list and permissions data from the one or more databases 212.In an alternative embodiment (not shown), the multiplexing gateway 202may be located remotely from the global provider site 200. In oneaspect, various global provider sites 200 or task management computers16 may exist, each separately hosting a task management server 210 andassociated database 212. In such a case, the multiplexing gateway 202would be located remotely from the global provider sites 200 to allowfor more efficient routing of requests to the various task managementservers 210 (described below).

Multiplexing Gateway Server

In order to provide flexibility in the configuration of the taskmanagement system 2, many embodiments of the invention include amultiplexing gateway server 202. The multiplexing gateway is a serverresponsible for routing requests from one or more connected clientprograms to one or more connected task management servers (such as thetask management server(s) 210 and the local task management server 238)based on the type of request and the location of the associated data,consolidating the responses from the task management servers and routingthe response data to the requesting client program. For example, in theembodiment of the invention illustrated in FIG. 2, the multiplexinggateway server 202 routes requests from various client programs(associated for example with remote users 222, 224 or local users 232,242) to multiple task management servers 210 as well as local taskmanagement servers 238 hosted at local customer sites 230. The varioustask management servers (e.g., 210 and 238) respond to the requests byaccessing and manipulating user, task-list, task, and permission datastored on global databases 212 and local databases 240. The multiplexinggateway server 202 consolidates the responses from the various taskmanagement servers 210, 238 into a single communication back to therequesting client program.

The multiplexing gateway server 202 determines to which of the varioustask management servers to route the request. When the client programrequests updates to the user's catalog display, for instance, themultiplexing gateway server 202 replicates the request to every taskmanagement server in the task management system 2, awaits the responsefrom each of the task management servers, and combines the response datainto a single response to the requesting client program. In response toother requests, such as updating a specific task-list or task, themultiplexing gateway 202 may route the request to the appropriate taskmanagement server which hosts the task-list or task related data. One ofordinary skill in the art will appreciate that various parameters of thetask management system 2 may be established in order for themultiplexing gateway server 202 to route requests to one or moreappropriate task management servers, and that various techniques may beused to perform the routing.

Permissions

A user's visibility and permissions to the various tasks and task-listsare managed intrinsically by the task management computer 16 in responseto users' interactions. FIGS. 3A and 3B illustrate several of theseinteractions, in sequence, although these interactions can be performedindependently of each other, or in various other sequences (not shown).Additionally, the “Permissions” shown in FIGS. 3A and 3B are illustratedas tables for exemplary purposes only, and are not intended to limit thepermissions data of the task management system 2 to be created or storedas shown in these figures. Although FIGS. 3A and 3B are described belowwith reference to the task management computer 16 of FIG. 1, it is to beunderstood that these embodiments could be performed by the globalprovider site 200 as depicted in FIG. 2 (see Structure of Exemplary TaskManagement System, above).

On a general level, and in the embodiments shown in FIGS. 3A and 3B,there are three levels of permissions associated with users in relationto task-lists or tasks (see Table 1, below). These permissions are“all”, “basic”, and “none”, and allow a user to have various levels ofinteraction with the task-lists and tasks of the system, as will beunderstood from the descriptions below. As may be appreciated, “Basic”permission can range from being very expansive (only slightly lessrestrictive than “All”), or very limited (only slightly more expansivethan “None”).

As depicted in FIG. 3A, when User A creates a new task-list, Task-List 1(TL1) at step 301, the task management computer 16 creates a permissionsrecord for User A 321 giving User A “All” permissions to TL1 and storesthis permissions record in the database 18. User A can then “invite”another user to join or “watch” the new task-list, TL1. “Watching” atask or task-list, in various embodiments of the task management system2, refers to: (1) a user indicating an interest in the task, such thatit will appear or be visible in a portion of the user's catalog(described below); and (2) being joined to a task-list (describedfurther below). In one embodiment, users do not have to be “known” toeach other in order to invite other users to join a task-list. In otherembodiments, User A may be limited to inviting only “known” users tojoin TL1. At step 302, User A invites User B to join TL1. In response,the task management computer 16 creates a permissions record for User B322 giving the user “Basic” permissions necessary to access thetask-list. If User B chooses to accept the invitation, in other wordsdecides to watch TL1, at step 403, the task management computer 16changes the permissions record for User B to indicate User B is watchingthe task-list 323. In various embodiments, information indicating a useras “watching” or being “assigned” to a task-list or task could be storedseparately from the permissions record.

User A can create a new task, TASK1, as a member of task-list TL1 atstep 304. Upon doing so, a permissions record is created for User A 324assigning the user permissions to TASK1 and indicating that User A iscurrently assigned responsibility to the task. In one embodiment, User Ais explicitly given “Basic” permissions to TASK1 but has effectivepermissions of “All” inherited from the parent task-list TL1. In anotherembodiment, User A, as the original creator, may be assigned “All”permissions to the created task, in order to manage and administrate thepermissions of others to that task, regardless of the user's permissionsfor the parent task-list. Note that although no specific permissionsrecord is created for User B for TASK1, User B still has “Basic”permissions to TASK1 by virtue of the user's “Basic” permissions totask-list TL1 325. In other words, in the absence of a specificpermissions record, User B “inherits” permissions to TASK1 from User B'scorresponding permissions to the parent task-list TL1. If User A decidesto assign responsibility for TASK1 to User B at step 305, the taskmanagement computer 16 will create a permissions record for User B 327giving the user “Basic” permissions to the task and indicating that UserB is currently assigned responsibility for the task. The task managementcomputer 16 will also update the permissions record for User A for TASK1326 to indicate that User A is no longer responsible for the task. Inone aspect, assigning a task to another user signifies an indicationthat the other user is responsible for the task. This may signify thatthe other user is responsible for completing the task, or may onlysignify that the other user is responsible for completing or handlingone portion of the task. Thus, the task management system 2 isconfigured to allow more than one user to be assigned to a particulartask throughout the task's existence. In one embodiment, only one usermay be assigned to a task at any given time. In various otherembodiments, the task management system 2 may be configured to allow atask to be assigned to various users at any given time.

Continuing as depicted in FIG. 3B, if User B creates a new task, TASK2,as a member of task-list TL1 306, a permissions record is created forUser B 328 giving the user “Basic” permissions to TASK2. As describedabove, since no specific permissions record is created for User A forTASK2, User A's permissions for TASK2 are inherited from the user's“All” permissions to task-list TL1 329. In alternative embodiments (notshown), because User A is not the original assignee or creator of thetask, TASK2, the task management system 2 may be configured to allowUser A to inherit only some permissions from the parent task-list, andthus effectively giving User A only “Basic” permission. If User Bdecides to assign responsibility for the task TASK2 to User C at step307, the task management system 2 determines first if User C is “known”to User B, at step 308 (described below). If so, the task managementcomputer 16 will create a permissions record for User C 331 giving theuser “Basic” permissions to TASK2 and indicating that User C iscurrently assigned responsibility for the task. Note that although UserC has basic permissions to the task, that user has no permissions to theparent task-list 330. Because User C has no permissions to the parenttask-list TL1, User C also will have no permissions to any other tasks(such as TASK1 332) in the task-list, unless User C has explicitly beengranted permission to a task (e.g., by having been assigned to a task,such as TASK2 331).

The task management computer 16 intrinsically manages the permissions asdescribed above, and also provides the capability for users tomanipulate the permissions for other users to tasks and task-listsdirectly or explicitly, as well as to establish more specificpermissions for each user giving the system broad flexibility in thepresentation of tasks and task-lists to users. The following table,Table 1, shows the elementary permissions managed intrinsically by thetask management computer 16 and their effect:

TABLE 1 Object Permission Effect Task-List None User may not access,watch, or modify the task-list at all. Task-List Basic User may watchthe task-list, start new tasks, and grant other users “basic” access(i.e., by inviting other users to watch the task-list). Task-List AllUser may remove or customize permissions for other users, as well asmaintain task-list properties, e.g. name and description. Task None Usermay not read or add task comments; may not close or re-open a task. Usermay not watch the task. User may not read any updates to the taskdescription since the task was started. If the user does not have readaccess on the task's task-list, then the user may not access the task atall. Task Basic User may watch, comment, close, re-assign or update thecontents of the task. User may also grant basic access to the task toother users. Task All User may remove or customize task permissions forother users.

In addition to the above, users can explicitly can grant or deny thefollowing more specific permissions to other users:

TABLE 2 Object Permission Effect Task-List access User can see name anddescription of task-list Task-List read User can see initial name anddescription of tasks within the task- list Task-List post User cancreate new tasks Task-List delown User can delete tasks that theystarted, which removes their visibility from the task-list. This doesnot close the task. Task-List join User can watch the task-list and seenew tasks as they are created Task-List delall User can delete anytasks, which removes their visibility from the task-list. This does notclose the task. Task-List admin User can change permissions for otherusers. Task access User can see name, description, assigned user, andstatus of the task Task read User can read the task's comments Task postUser can make comments Task delown User can remove comments that theymade. Task join User can watch the task and see new comments and statuschanges are the task is updated. Task delall User can delete anycomments Task admin User can change permissions for other users.

As previously noted, if a particular user has no explicit permissionsfor a task, the user's permissions are inherited from the parenttask-list. This applies for the more specific permissions as well (seeTable 2). For example, if a user has been explicitly granted “post”permission to a task but not “read” permission, the user's ability tosee comments on the task added by other users will depend upon thatuser's permissions for the parent task-list. On the other hand, if auser has been explicitly denied “read” permissions on a task, that userwill not be able to see comments from other users regardless of theparent task-list permissions. As may be appreciated, the flexibility ofthe task management system 2 may allow for various other uniquepermissions models or scenarios. For example, the task management system2 is configured so that when a user explicitly changes the permissionsof a task within a task-list, this overrides the task-list permissions,but does not change them. Additionally, if a user loses permission to atask-list, that user will lose permissions to tasks within that list,unless the user has been granted additional permissions to a task withinthat task-list (such as by having been assigned to the task).

Known Users and Prevention of “Spam”

In many embodiments of the invention, the task management system 2 ismaintained globally, i.e. all users, task-lists, and tasks, are part ofone large system regardless of any real-world affiliations or virtualsegments of the user population. This allows one user to see andmaintain one single view of tasks that span multiple spheres ofinterests, e.g. tasks and task-lists for work and tasks and task-listsfor home, but it also creates a potential situation where a first usercan assign tasks to a second user to force the task to become visible tothe second user even though the second user has no affiliation with orinterest in the first user. This would create the equivalent of “spam”email in that it would allow the first user to impose an assignment of atask upon the second without his consent or force another user to watcha task-list. In order to prevent such “spamming” of tasks andtask-lists, embodiments of the present invention utilize two concepts:the “known user” and a two-step process of invitation and acceptance towatch task-lists.

Two users, such as User A and User B, are “known” to each other if thereexists any task or task-list which both users are currently watching orjoined, as represented by area 720 in FIG. 7. This creates an implicit“group” of known users to which User A may assign tasks. Further, forUser B to watch a task-list requires a two-step process: (1) User A must“invite” user B to watch the task-list, thus implicitly setting thepermissions for User B to the task-list and thereby giving User B“access” to the task-list, as described above; and (2) User B must“accept” the invitation by affirmatively choosing to watch thetask-list. Requiring this two-step process prevents the situation whereUser A can force User B to watch User A's task-list without user B'sconsent.

In an alternative embodiment (not shown), User A can invite User B tojoin TL1 at step 302, only if User B is known to User A. If User B isnot known to User A, the task management computer 16 returns an errormessage to User A indicating, for example, that only known users of thesystem can be invited to join TL1.

As can be seen in FIG. 3B, in one embodiment, when User B desires toassign TASK2 to User C, the task management computer 16 is configured toallow this assignment only if User C is known to User B. In doing so,the task management computer 16 determines at step 308 if User B andUser C are currently watching a common task or task-list. If so, thetask management computer 16 permits the assignment and User C'spermissions to TASK2 are set to “Basic” as described above. If not, thetask management computer 16 returns an error message to User B,indicating, for example, that TASK2 may only be assigned to a “known”user. In other embodiments, assignments may be allowed based on otherexisting relationships between users.

Because the task management system 2 is configured to prevent users from“spamming” each other with task assignments or forcing other users towatch task-lists, it is assumed that upon initial implementation of thesystem, all users would be strangers to one another. In such a case, theusers would be unable to assign tasks to other users or force otherusers to join task-lists. Therefore, the task management system 2 isconfigured to allow users to manually input the usernames or emailaddresses of other users of the system, when desiring to invite theseother users to join a task-list. In various embodiments, this may alsobe possible when assigning a task to other users. In one embodiment, ifUser A desires to invite User B to join a task-list, but Users A and Bare not “known” to each other within the system 2, User A could inputUser B's username or handle (such as “User B”) and User B would be givenBasic permissions to the task-list (as described above). In anotheraspect, if User A desires to assign a task to User B, for instance, UserA could input User B's email address, and the task management computer16 would be configured to generate an email to User B indicating thatUser A desires to assign a task to User B. As can be appreciated by oneof skill in the art, if User B was not yet a user of the system 2, theemail may also provide a hyperlink or other means for allowing User B toregister for the task management system 2.

In another embodiment (not shown), an individual at a local customersite 230 may desire to register multiple users at once (such as allemployees at a company), and indicate that these users would be known toeach other upon registration, so that they can immediately begin sharingwork-related tasks, for instance.

Audience Selection

As the number of task-lists and tasks that User A is watching increases,so too will the number of users known to User A. Therefore, in variousembodiments of the present invention, the task management computer 16 isconfigured to present a list of known users to User A, in response toUser A indicating a desire to invite another user to a task-list, orassign a task to another user. For example, after User A has createdTASK1, as shown at step 304, User A may desire to assign TASK1 toanother user. In order to simplify this interaction, the task managementcomputer 16 populates a list of potential users who may be assigned thetask. In one embodiment, shown in FIG. 5, the list is a heuristic listand presents the most probable order of users to which User A would wantto assign the task. FIG. 5 represents one embodiment of populating aheuristic list, although the “most probable” order can vary from thatshown in FIG. 5.

As shown in FIG. 5, the task management computer 16 first adds to thelist all users who are watching the task and have previously beenassigned the task. Because User A created the task, User A isautomatically designated as watching the task by the task managementcomputer 16. Therefore, in one embodiment, User A would be the firstuser on the list. However, because the task management system 2 isconfigured to allow a task to be assigned to various users throughoutits life, several additional users may be added to the list at step 502.The task management computer 16 at step 504 then adds to the list allother users who are watching the task and, by implication, have not beenpreviously assigned to the task. At step 506, all other users that havebeen previously assigned to the task, but are not also watching thetask, are added to the list. At step 508, the task management computer16 adds to the list all other users who are watching the task-list towhich the task belongs. At step 510, the task management computer 16adds to the list all other users who have been invited to watch thetask-list to which the task belongs, but who have not actively chosen todo so. Finally, all other known users are added to the list at step 512.As described above, these are users who are watching a task or task-listin common with User A, but who did not fit into the groups identifiedabove at steps 502-510.

As can be appreciated, because the permissions of the task managementsystem 2 are constantly changing as users create task-lists and tasks,assign tasks to others, invite others to join task-lists, etc., theheuristic list is configured to be updated accordingly. Thus, each timeUser A chooses to assign a task to another user, for instance, the listof potential users presented to User A may be different.

In another embodiment, the task management system 2 is configured tosimplify the list and place User A, along with all other users who havebeen assigned to the task at some point at the beginning of the list,followed by those users who are watching the task-list to which the taskbelongs, those users who have access to the task-list, and all other“known” users. In other embodiments (not shown), the task managementsystem 2 is configured to be flexible and add users to the list invarious other sequences.

As described above, a user (e.g., User A) may desire to invite an“unknown” user (e.g., User X) to a task-list, or may desire to assign atask to an “unknown” user. In this case, User X's name would not appearon the list presented to User A. Thus, in one embodiment (not shown),User A may be presented with an option at the bottom of the list, suchas “Select another user”. Upon selection of this choice, User A couldinput User X's username or email address, as described above.

Catalog of Tasks and Task-Lists

The task management system 2 allows users to see the tasks andtask-lists that they are watching, through a catalog, as can be seen inFIG. 8. Generally, the catalog presents to the user, in a visiblemanner: (1) tasks assigned to that user, and (2) task-lists or tasksthat a user is watching. However, in various embodiments, more or lessinformation may be visible to a user. By watching tasks, a user ispresented with notifications when the status of a task changes, or whennew comments have been added to the task.

FIG. 8 illustrates an exemplary screen shot of one embodiment of a userinterface of the task management system 2, which also illustrates thecatalog of tasks and task-lists. The upper portion 802 (“User A'sTasks”) of the catalog represents the tasks to which User A is assigned,such as “Call Mr. Smith”, and “Go grocery shopping”. In one embodiment,the catalog also presents the parent task-list to these tasks. Forinstance, the task “Call Mr. Smith” falls under the “Work” task-list andthe task “Go grocery shopping” falls under the “Home” task-list. In oneembodiment, the task management system 2 is configured to automaticallyforce a user to watch any tasks that are currently assigned to them. Thecatalog also presents the status 804 of the tasks that are assigned toUser A, such as “Active” or “Closed”. User A may desire to view thedetails of the task (such as by double-clicking on the task name, orother method known in the art), in order to see comments or notes whichUser A's spouse may have added to the task (not shown). As may beunderstood, comments or notes may be added to tasks to indicateadditional information that is relevant to the tasks. For example, UserA may add a comment to the task “Anniversary Dinner”, indicating that“Reservations 7:00 p.m., at Chez Moi restaurant”. If User A's spouse wasalso assigned this task, or was watching this task, and had therequisite permissions to read comments on the task (see above), thenUser A's spouse would be notified of updates to the task, and would beable to see the details of the “Anniversary Dinner” task.

The lower portion 810 (“Watched Tasks”) of the catalog represents thetasks which User A has chosen to watch, but are not assigned to User A.For example, User A may have been invited by another user to jointask-list “Company Tasks”. User A may have chosen to join or watch thetask-list. Upon doing so, the task-list “Company Tasks” would appear inUser A's “Watched Tasks” portion 810, as well as all tasks falling underthis task-list, such as “Co-worker Task” and “Employee Picnic”, as shownin FIG. 8. As tasks are added to the “Company Tasks” task-list, theywill automatically appear in User A's catalog, since he is watching theparent task-list. The task management system 2 also presents the status814 of these watched tasks to User A, as described above with regard toUser A's assigned tasks. This allows User A to see which tasks are stillactive, and which have been closed. Additionally, because the tasksfalling under the “Watched Tasks” portion 810 are not assigned to UserA, the catalog indicates which users of the system 2 are assigned to thetask 812.

The task management system 2 allows a user to “Ignore” 816 one or moretasks falling within the “Watched Tasks” portion 810 of a user'scatalog, in order to allow the user to personalize and manage thecatalog. For example, User A may select to watch “Company Tasks”, and asdescribed above, this results in User A automatically watching all tasksfalling within “Company Tasks”. The number of member tasks to this listcan be very high, and thus User A may only desire to watch certain tasksand ignore all others. User A can also “collapse” 818 certaintask-lists, so that only the name of the task-list would be visible, butthe tasks within the task-list would be hidden, as can be appreciated byone of ordinary skill in the art.

In another aspect, User A can choose to view tasks assigned to anotheruser (not shown) by viewing the upper portion 802 of another user'scatalog. In this embodiment, User A can view only those tasks to whichUser A has permission to view. For example, if User A chooses to viewall tasks assigned to User B, User A will be able to see only thosetasks to which User A has at least Basic permission or those taskscontained within task-lists to which User A has Basic permissions. Thesubset of User B's tasks which User A has permission to view isrepresented by the area 710 in FIG. 7.

Differential Update

In many embodiments of the invention, much of the consumption or networkbandwidth available to the task management computer 16 results from thefrequent updating of the status of the tasks displayed in the user'scatalog. One embodiment may contain client programs that update thecatalog of currently active users through requests to the various taskmanagement servers at various intervals (such as every 30 seconds). Toreduce the load, one embodiment of the task management system includes aDifferential Update feature which stores data for each user thatcontains the “last seen state” of each task or task-list for which theuser is watching, and responds to catalog update requests with onlyinformation that has changed since this “last seen state”, thus reducingnetwork traffic.

As illustrated in FIG. 6, when a user chooses to watch a particular itemsuch as a task or task-list at step 610, the client program at step 612indicates to the task management server 210 the “last seen state” of theitem, i.e. the current state of the item viewed by the user at the timethe user chooses to watch the item. The task management server 210stores this “last seen state” data for the user at step 614 in thedatabase 212. In subsequent requests by the user for the details of theitem, such as update requests to the user's catalog display (e.g., atstep 620), the task management server 210 retrieves the “last seenstate” data for the item at step 622 from the database 212 and respondsonly with data for the item which has changed since the “last seenstate” at step 624. The client program subsequently updates the “lastseen state” and sends the data to the task management server 210 forstorage in the database 212 to reflect the “last seen state” of theitem, at step 628. It is to be appreciated that the process can berepeated as User A requests to watch various tasks or task-lists orrequests various other updates of User A's catalog, for example.

The Differential Update feature thus allows the task management system 2to handle a much greater number of users with more frequent updateswhile consuming less network bandwidth.

Task-List Aliasing

In one embodiment of the present invention, the task management system 2provides a task-list aliasing feature which allows for one set of tasksto be members of multiple task-lists. An example illustrated in FIG. 4shows a task-list (TASK-LIST 1) 410 with a name 412, description 414,and user permissions data 416. TASK-LIST 1 also contains one or moretasks 430, each with a name 432, description 434, currently assigneduser(s) 436, user permissions 438, and notes and comments 440. Thetask-list aliasing feature allows one or more new task-lists (ALIASTASK-LIST) 420 to be created, each with their own name 422, description424, and user permissions data 426, but containing the same set of tasksas the first task-list, TASK-LIST 1. Note that the tasks 430 are notduplicated in each alias task-list. Rather, the individual tasks 430 aremembers of both TASK-LIST 1 410 and each ALIAS TASK-LIST 420. Thus, if atask is created in TASK-LIST 1, this task will automatically become amember of any alias task-lists of TASK-LIST 1, and vice versa.

The task-list aliasing feature provides flexibility in the management oftasks across multiple groups or organizations, such as multiple localcustomers associated with a local customer site 230, and/or multipleremote users 222, 224. For example, if a software development companynamed “Software Inc.” had a customer named “Customer Co.”, they may wishto share a task-list for the monitoring and management of tasksassociated with development of Customer Co.'s website. However, eachcompany may want to see the task-list in a different way. For example,Software Inc. would probably want to see a task-list named or describedas “Customer Co. Website Project”, whereas Customer Co. would want tosee a task-list named or described as “Website Project”. Further,Customer Co. may want to explicitly set permissions for projectmanagement personnel to the task-list to allow creation of tasks, butnot assignments or changes in status. Software Inc. would want the taskmanagement system 2 to inherently manage the task-list permissions.

The task-list aliasing feature allows the task management system 2 tosatisfy both Software Inc. and Customer Co.'s requirements by allowingeach to create and configure their own task-list, and have bothtask-lists share the same set of member tasks.

CONCLUSION

Many modifications and other embodiments of the inventions set forthherein will come to mind to one skilled in the art to which theseinventions pertain having the benefit of the teachings presented in theforegoing descriptions and the associated drawings. Therefore, it is tobe understood that the inventions are not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

1. A task management system connected to a communication network withone or more users operating respective computing devices, the systemcomprising: one or more task management computers executing anapplication, with which said users interact via respective computingdevices, the task management system being configured to enable one ormore first users to generate a designation of one or more second usersto a task-list or a task, the task being a member of one or moretask-lists, said task-list and task having associated permissions, thetask management computer changing automatically said permissions of saidtask-list and said task with respect to said second users based on saidfirst-user designation.
 2. The task management system of claim 1,wherein said first-user designation comprises a selection of one or moresecond users to join a task-list, said selection being made from a listof one or more potential second users who may join said task-list. 3.The task management system of claim 2, wherein said list of potentialsecond users is a heuristic list, said heuristic list being configuredto present to said first user the most probable order of second userswhom said first user would desire to join a task-list, with the mostprobable second users being placed at the beginning of said list, andthe least probable second users being placed at the end of said list. 4.The task management system of claim 2, configured to enable said secondusers, that were selected by said first user, to choose to join saidtask-list in response to said first-user designation.
 5. The taskmanagement system of claim 1, wherein said first-user designationcomprises a selection of one or more second users to be made responsiblefor a task, said selection being made from a list of one or morepotential second users who may be made responsible for said task.
 6. Thetask management system of claim 5, wherein said list of one or morepotential second users comprises users of the task management system whoare joined to at least one task-list in common with said first user. 7.The task management system of claim 6, wherein said list of potentialsecond users is a heuristic list, said heuristic list being configuredto present to said first user the most probable order of second usersthat said first user would desire to specify as being responsible forsaid task, with the most probable second users being placed at thebeginning of said list, and the least probable second users being placedat the end of said list.
 8. The task management system of claim 7,wherein said most probable order of second users, listed in order, is:said first user, along with all other users who have been specified asbeing responsible for said task; users who have chosen to join thetask-list to which said task belongs; users who have been selected tojoin said task-list, but who have not chosen to join said task-list; andall other users of the task management system who are joined to at leastone task-list in common with said first user.
 9. The task managementsystem of claim 1, further comprising: a multiplexing gateway server,configured to receive a request from a user, including at least saidfirst-user designation, transmit said request to one or more taskmanagement computers, receive a response from said task managementcomputers, and transmit said response to said user.
 10. The taskmanagement system of claim 9, wherein one or more of said taskmanagement computers are located locally to said multiplexing gatewayserver.
 11. The task management system of claim 9, wherein one or moreof said task management computers are located remotely from saidmultiplexing gateway server.
 12. The task management system of claim 1,configured to allow multiple task-lists to share a common set of membertasks, each task-list maintaining unique task-list attributes, such astask-list name, task-list description, and task-list permissions. 13.The task management system of claim 12, configured to: receive a requestfrom one of said users to create a task as a member of a first task-listof said multiple task-lists, said task inheriting automatically saidfirst task-list permissions; and automatically designate said task as amember of said other multiple task-lists.
 14. The task management systemof claim 1, configured to present to each of said users a catalog oftask-lists and tasks, comprising: tasks for which said user has beenmade responsible by said first-user designation; task-lists that saiduser has been invited to join, by one or more other users by saidfirst-user designation, and has chosen to join; and tasks that aremembers of task-lists that said user has been invited to join and haschosen to join.
 15. The task management system of claim 14, configuredto keep said user aware of changes to said catalog of task-lists andtasks by: (a) displaying a presentation of said task-lists and tasks tosaid user; (b) storing the state of said task-lists and tasks, at thetask management computer, at the time of said presentation to said user;(c) providing, at established time intervals, only changed informationfrom the time when the state of said task-lists and tasks was stored atstep (b); and (d) repeating steps (a)-(c).
 16. A computer-readablestorage medium storing an application for shared task management among aplurality of users, said application directing a computer to perform thesteps of: (A) receiving from a first user a designation of one or moresecond users to a task-list or task, the task being a member of one ormore task-lists, said task-list and task having associated permissions;and (B) automatically changing said task-list and task permissions basedon said first-user designation.
 17. The computer-readable storage mediumof claim 16, wherein step (A) comprises receiving from said first user aselection of one or more second users to join a task-list.
 18. Thecomputer-readable storage medium of claim 16, wherein step (A) comprisesreceiving from said first user a selection of one or more second usersto be made responsible for a task, and enabling said first user to makesaid selection from a list of potential second users who are joined toat least one task-list in common with said first user.
 19. Thecomputer-readable storage medium of claim 18, wherein said applicationfurther directs said computer to perform the step of: generating saidlist of potential second users, said list being a heuristic listconfigured to present to said first user the most probably order ofsecond users that said first user would desire to specify as beingresponsible for said task, with the most probably second users beingplaced at the beginning of said list, and the leas probable second usersbeing placed at the end of said list; said step of generating said listoccurring prior to said step of enabling said first user to make saidselection from said list.
 20. The computer-readable storage medium ofclaim 16, wherein said application further directs said computer toperform the step of: present to said plurality of users a catalog oftask-lists and tasks, said catalog comprising: tasks for which saidplurality of users has been made responsible by said first-userdesignation; task-lists that said plurality of users has been invited tojoin, by one or more other users by said first-user designation, and haschosen to join; and tasks that are members of task-lists that saidplurality of users has been invited to join and has chosen to join.